home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000395_news@columbia.edu _Tue Jul 9 22:36:39 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id WAA17163 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 9 Jul 1996 22:36:39 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id WAA20600 for kermit.misc@watsun; Tue, 9 Jul 1996 22:36:38 -0400 (EDT)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!howland.reston.ans.net!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Telnet to Linux Hangs
  8. Message-ID: <1996Jul9.095251.82500@cc.usu.edu>
  9. Date: 9 Jul 96 09:52:51 MDT
  10. References: <4rsi4b$1vl@mochi.lava.net>
  11. Organization: Utah State University
  12. Lines: 54
  13.  
  14. In article <4rsi4b$1vl@mochi.lava.net>, really@lava.net (Geckos'R'Us) writes:
  15. > Aloha tekkies,
  16. > 
  17. > We have a mixed environment of several flavors of unix and netware mostly
  18. > talking TCP/IP but also with modem dialups and serial port connections.
  19. > We have tried to standardize on Kermit 3.14 as our terminal emulator because
  20. > (1) it can handle TCP/IP, direct connections and modem dialups, (2) it has
  21. > a lot of nice features we like (3) it is fairly customizable and of course
  22. > (4) other than documentation and setup, it is basically free.
  23. > 
  24. > We use the Crynware Packet drivers to enable PC TCP/IP connections to our
  25. > unix/novell systems.  This worked well UNTIL we decided to replace our
  26. > outmoded X.25 connection to the internet via an ancient UNISYS unix
  27. > minicomputer with a more common CISCO router ethernet connect primarily
  28. > connected through two Pentium Linux machines.
  29. > 
  30. > The problem: Kermit 'dies' when it uses its telnet connection to one of these
  31. > Linux machines.  This does NOT occur when telnetting to the UNISYS, Sequent
  32. > or Interactive Unix machines.  It also does NOT occur if I use NCSA's telnet
  33. > instead of Kermit.
  34. > 
  35. > Having exhausted all the likely paramaters changes to Kermit's mskermit.ini
  36. > file and making numerous change attempts to our Linux files, it have been
  37. > unable to find a solution.  I HAVE determined that Linux is killing the
  38. > Kermit telnet session 'as if by a cron'.  It kills the session precisely at
  39. > the same *second* on the Linux box each time.  (I reset the DOS-client
  40. > machine's time to see if this made any difference: NO.  I rebooted the Linux
  41. > box to see if the time-of-kill changed: YES.)
  42. > 
  43. > Having consulted with the BIG-LINUX listserv group, there were several
  44. > suggestions, but none that worked.  The Linux gurus seemed to suggest that
  45. > either there is a bug in the Linux telnetd "keep-alive" code or that Kermit,
  46. > unlike NCSA telnet, is not sending the right signals to enable Linux's
  47. > telnet "keep-alive" code.
  48. > 
  49. > Since telnetting to our Linux PC's (our primary internet access) is critical
  50. > to our normal functioning, we must find a solution to this problem or be
  51. > forced to abandon Kermit 3.14 as our standard communication program.
  52. > 
  53. > Thanks in advance for any insights/solutions you may have.
  54. > 
  55. >        Bob Carroll, systems programmer  really@lava.net
  56. ---------
  57.     Yes, there is a bug in the MS-DOS Kermit keepalive code, in v3.14.
  58. Yes, Linux is loaded with bugs too.
  59.     This and other problems are "solved" in MSK v3.15/development. We
  60. will announce an open testing period as development continues on MSK 3.15
  61. so watch this News group for the notice. 
  62.     Please keep in mind this will be a fluid development environment so 
  63. please don't become locked into the test material. However, the more beating
  64. on it the better, as IBM and MS have demonstrated over the past couple of 
  65. years. I have a busy travel schedule this month so reports will likely stack 
  66. up without response until I get a chance to go through each report in detail.
  67.     Joe D.